home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17824 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.6 KB  |  53 lines
  1. Newsgroups: comp.lang.java,comp.lang.c++,comp.sys.mac.oop.misc,comp.lang.basic.visual.misc,comp.sys.mac.programmer.misc,comp.windows.misc
  2. Path: Unify.com!lee
  3. From: lee@Unify.com (Lee Crocker)
  4. Subject: Re: java vs. multi-platf. frameworks ?
  5. Message-ID: <Dq0rq5.9sz@unify.com>
  6. Sender: news@unify.com
  7. Nntp-Posting-Host: zanzibar.sac.unify.com
  8. Organization: Unify Corporation (Sacramento)
  9. References:  <3171A3EA.3F27@dma.epfl.ch>
  10. Date: Wed, 17 Apr 1996 18:37:17 GMT
  11.  
  12. In article <3171A3EA.3F27@dma.epfl.ch>, Michel Tourn <tourn@dma.epfl.ch> writes:
  13.  
  14. > So, before we trash some C++ framework solution in favour of java, I
  15. > would like to hear good reasons of doing so or not.
  16. > . . .
  17. > F. Java, its IDEs, its AWT, its available class libraries  will be
  18. > appropriate for this task, but not now. 
  19. > A. When ?
  20.  
  21. The inadequacy of AWT would be compelling for me.  Sun has committed
  22. to adding a few gadgets, but I have seen nothing from them, or from
  23. anyone else, that AWT or some other toolkit will ever be capable of
  24. serious application development.  That is not to say that it won't
  25. happen--just that I see no plans right now, so I'd be very wary of
  26. spending development time betting on some future change in AWT.
  27.  
  28. Sun's current attitude about AWT offers little hope.  They seem to
  29. think that they can achieve portability by making AWT a subset of the
  30. functionality of existing GUIs; but that attitude is backwards.  To be
  31. truly portable, it must be a superset of existing GUIs, emulating those
  32. functions specific to each on the others in a portable way, and letting
  33. developers query the system for its capabilities in a portable way.
  34.  
  35. There is never any excuse to sacrifice functionality for portability.
  36. Ever.  Users demand--and rightly so--that they be able to take full
  37. advantage of every dollar they've spent on their hardware and software,
  38. and if they hear "well, we could do that but it wouldn't be portable"
  39. from a vendor, they'll go to a vendor that will do it non-portably.
  40. As a developer, if I can earn 10 cents more by writing a non-portable
  41. program, I will, without the slightest twinge of guilt.
  42.  
  43. The only way to ensure portability, therefore, is the ensure that a
  44. portable program is capable of doing everything the software needs 
  45. to do, and AWT doesn't even come close.  The glaring omissions for
  46. me are things like right-button popup menus, native video support
  47. (for example, being able to query the system for its color capabilities
  48. and things like monitor gamma, and then optimizing my diplay for it),
  49. portable virtual keys for things like arrow and cut/paste, better
  50. font metrics, and about 1000 more system properties.
  51.  
  52. Just one man's rant.  Thanks for the soapbox :-)
  53.